home *** CD-ROM | disk | FTP | other *** search
/ QRZ! Ham Radio 4 / QRZ Ham Radio Callsign Database - Volume 4.iso / digests / digital / 940285.txt < prev    next >
Internet Message Format  |  1994-11-13  |  18KB
  1. Date: Fri, 26 Aug 94 04:30:20 PDT
  2. From: Ham-Digital Mailing List and Newsgroup <ham-digital@ucsd.edu>
  3. Errors-To: Ham-Digital-Errors@UCSD.Edu
  4. Reply-To: Ham-Digital@UCSD.Edu
  5. Precedence: Bulk
  6. Subject: Ham-Digital Digest V94 #285
  7. To: Ham-Digital
  8.  
  9.  
  10. Ham-Digital Digest          Fri, 26 Aug 94       Volume 94 : Issue  285
  11.  
  12. Today's Topics:
  13.                        HF -> internet gateways?
  14.                         HF Packet (Mac vs PC)
  15.                      HP100LX + Baycomm = Success?
  16.                      jnos trace question (2 msgs)
  17.                            jnos w/enet card
  18.      mlhacker.zip - Zenith Minisport docs, hints, hacks & goodies
  19.                     Packet Routing with JNOS 110f
  20.                       What SB for Digital modes?
  21.  
  22. Send Replies or notes for publication to: <Ham-Digital@UCSD.Edu>
  23. Send subscription requests to: <Ham-Digital-REQUEST@UCSD.Edu>
  24. Problems you can't solve otherwise to brian@ucsd.edu.
  25.  
  26. Archives of past issues of the Ham-Digital Digest are available 
  27. (by FTP only) from UCSD.Edu in directory "mailarchives/ham-digital".
  28.  
  29. We trust that readers are intelligent enough to realize that all text
  30. herein consists of personal comments and does not represent the official
  31. policies or positions of any party.  Your mileage may vary.  So there.
  32. ----------------------------------------------------------------------
  33.  
  34. Date: 25 Aug 1994 23:37:22 GMT
  35. From: andyh@ucsd.edu
  36. Subject: HF -> internet gateways?
  37. To: ham-digital@ucsd.edu
  38.  
  39. i'm looking for gateways which can receive pactor, amtor, gtor or
  40. rtty messages on HF and send them to an internet e-mail address.
  41.  
  42. i'd be most grateful if anyone who knows of such things could 
  43. email me details. i'll compile and post the results.
  44.  
  45. thanks,
  46.  
  47. andy howard <andyh@burn.ucsd.edu>
  48.  
  49. ------------------------------
  50.  
  51. Date: 25 Aug 1994 03:01:52 GMT
  52. From: news.sprintlink.net!sun.cais.com!news.cais.com!news@uunet.uu.net
  53. Subject: HF Packet (Mac vs PC)
  54. To: ham-digital@ucsd.edu
  55.  
  56. Go ahead and get a Mac for this project,the software needed for what
  57. you want to do exists and is sold by the major TNC manufacturers.
  58. I heartdly recomend a Kam all mode TNC and Hostmaster for Mac from
  59. Kantronics.If you cant get a source or number for the manufacturer,send
  60. me some e-mail,I'll get it to you
  61.  
  62. ------------------------------
  63.  
  64. Date: Thu, 25 Aug 1994 05:40:07 GMT
  65. From: ihnp4.ucsd.edu!dog.ee.lbl.gov!agate!usenet.ins.cwru.edu!news.csuohio.edu!sww@network.ucsd.edu
  66. Subject: HP100LX + Baycomm = Success?
  67. To: ham-digital@ucsd.edu
  68.  
  69. J. Sherwood Williams (jwill@cabell.vcu.edu) wrote:
  70. : 
  71. : Has anyone had any success using a Baycom type modem with the HP
  72. : 100LX palmtop? Before I go out and mess with it, it would be good
  73.  
  74. The HP100LX works fine once the Baycom is powered by a 9 volt battery.
  75. Works even better with a PacComm HandiPacket and MSYS.  With that it is a
  76. full forwarding BBS with all the goodies (node, etc.).  In that way
  77. I can forward to the home BBS when I have mail to deliver and the home
  78. BBS can forward into me ... if I am there or not.  We also ran it with a
  79. GTOR and Pactor port when running on a battery up in Algonquin Provintial
  80. Park.  Worked great and saved all kinds of amp-hours as I didn't have to
  81. use the other laptop.
  82.  
  83. I love it!
  84.  
  85. 73,
  86. Steve
  87.      ag807@cleveland.freenet.edu
  88.      no8m@no8m.#neoh.oh.usa.na
  89.  
  90. ------------------------------
  91.  
  92. Date: 25 Aug 1994 13:46:06 GMT
  93. From: noc.near.net!transfer.stratus.com!abersoch.sw.stratus.com!northup@uunet.uu.net
  94. Subject: jnos trace question
  95. To: ham-digital@ucsd.edu
  96.  
  97.     I have just started using jnos110f and have been having a problem
  98.     with having a trace show up on the screen. I can make it go to a
  99.     file.     What am I missing ?
  100.  
  101.     Bill
  102.  
  103. --
  104. --
  105.  
  106.     Bill Northup                   PHONE:       (508) 460-2085
  107.     Stratus Computer Inc.          INTERNET:       northup@sw.stratus.com
  108.     55 Fairbanks Boulevard       Packet:         N1QPR@WA1PHY.#EMS.MA.USA.NA
  109.     Marlboro, MA  01752            Amateur Radio:  N1QPR
  110.  
  111. ------------------------------
  112.  
  113. Date: 25 Aug 1994 08:16:23 -0700
  114. From: nntp.crl.com!crl4.crl.com!not-for-mail@decwrl.dec.com
  115. Subject: jnos trace question
  116. To: ham-digital@ucsd.edu
  117.  
  118. In article <33i7au$rr1@transfer.stratus.com>,
  119. northup@abersoch.sw.stratus.com (Bill Northup) wrote:
  120.  
  121. >   I have just started using jnos110f and have been having a problem
  122. >     with having a trace show up on the screen. I can make it go to a
  123. >     file.     What am I missing ?
  124.  
  125. An <F9> key.
  126.  
  127. After you have entered "Trace xxxx" <ENTER> (where "xxxx" is the
  128. representation of the type of trace you wish), mash the <F9> key to
  129. see the results.
  130.  
  131. You can tell if you mashed the key hard enough by observing the upper
  132. left corner of the CRT (3rd line down).  It will change from "Command"
  133. to "Trace". Mashing <F9> again will toggle back to Command Mode.
  134.  
  135. If you wish, you can use other F-keys to sequentially observe multiple
  136. active sessions; <F1> being session 1, <F2> being session 2, etc.
  137. Unfortunately, TRACE does not act like an independent session, and the
  138. TRACE screen will "freeze" if you are watching another session.
  139.  
  140. Lou
  141.  
  142. ------------------------Usual Disclaimers Apply-------------------------
  143. Internet:  lgenco@crl.com                    Lou.Genco@LChance.sat.tx.us
  144. Ham Radio Packet: N5SGL @ K3WGF.#SAT.TX.USA   tcp/ip: n5sgl@sat.ampr.org
  145. ------------------------------------------------------------------------
  146.  
  147. ------------------------------
  148.  
  149. Date: 25 Aug 1994 01:08:48 GMT
  150. From: ihnp4.ucsd.edu!dog.ee.lbl.gov!agate!library.ucla.edu!csulb.edu!nic-nac.CSU.net!charnel.ecst.csuchico.edu!csusac!csus.edu!netcom.com!ix.netcom.com!netnews@network.ucsd.edu
  151. Subject: jnos w/enet card
  152. To: ham-digital@ucsd.edu
  153.  
  154. I am running JNOS 1.10f and have installed gvc ethernet cards in my
  155. jnos pc and my other pc.  The cards check out fine between the machines
  156. running the diagnostics.  The supplied driver comforms to FTP specs. I
  157. have included the PACKET protocol in my config.h .   THe attach works
  158. fine, but I cannot get jnos to recognize the packets I am sending to
  159. it.  The trace on the port avails nothing.  Any ideas or suggestions
  160. for debugging would greatly be appreciated, especially configuration
  161. options for jnos I may not have set correctly.  Thanks.
  162. 73 de Bill Abernathy, kd5lu.
  163.  
  164. ------------------------------
  165.  
  166. Date: Thu, 25 Aug 1994 02:42:38 GMT
  167. From: ihnp4.ucsd.edu!dog.ee.lbl.gov!agate!howland.reston.ans.net!europa.eng.gtefsd.com!ulowell!simtel.coast.net!msdos-ann-request@network.ucsd.edu
  168. Subject: mlhacker.zip - Zenith Minisport docs, hints, hacks & goodies
  169. To: ham-digital@ucsd.edu
  170.  
  171. I have uploaded to the SimTel Software Repository (available by anonymous
  172. ftp from the primary mirror site OAK.Oakland.Edu and its mirrors):
  173.  
  174. SimTel/msdos/packet/
  175. mlhacker.zip    Zenith Minisport docs, hints, hacks & goodies
  176.  
  177. mlhacker.zip is a compendium of newsletters about the Zenith Minisport
  178. laptop computer and its use as a packet radio host computer.  Zenith
  179. offers only minimal and expensive support for this popular but
  180. discontinued 8086 compatible notebook computer.  Newsletters contain
  181. technical notes, construction projects, operating hints, resources,
  182. architecture details and other related goodies.  The Minisport Laptop
  183. Hacker series is the result of owning and repairing Minisports and
  184. donations from others on Internet and the Amateur Radio packet networks.
  185.  
  186. Special requirements: None
  187.  
  188. Changes: Compendium includes Minisport Laptop Hacker #1 - #22.
  189.  
  190. FreeText.  Uploaded by the author.
  191.  
  192. Brian Mork
  193. bmork@opus-ovh.spk.wa.us
  194. ka9snf@ka7fvv.#ewa.wa.usa
  195. 6006-B Eaker, Fairchild, WA 99O11
  196. V:509-244-3764  D:509-244-9260
  197.  
  198. ------------------------------
  199.  
  200. Date: 25 Aug 1994 11:51:22 GMT
  201. From: news.cerf.net!gopher.sdsc.edu!news.tc.cornell.edu!travelers.mail.cornell.edu!news.kei.com!yeshua.marcam.com!zip.eecs.umich.edu!newsxfer.itd.umich.edu!gatech!howland.reston@ihnp4.ucsd.edu
  202. Subject: Packet Routing with JNOS 110f
  203. To: ham-digital@ucsd.edu
  204.  
  205. I want to use JNOS as a packet switch between an AX25 serial link and an
  206. ether net segment.
  207.  
  208. With the autoexec.nos listed below, I can ping machines on the 1.0.0/24
  209. (ethernet) side of the net and I can ping machines on the 1.0.1/24
  210. (AX.25) side of the net.  The problem I have is that if I try to ping
  211. say 1.0.0.45 from 1.0.1.99, the packets dont go anywhere.  The default
  212. route on my AX.25 machine is set to:
  213.  
  214.     route add default sl1 1.0.0.99
  215.  
  216. The way I figure it, 1.0.0.99 should see the ping for 1.0.0.45 from
  217. 1.0.1.99 and route ot from the AX.25 side out onto the ether net side
  218. but this isn't hapening.  
  219.  
  220. Is there something I'm not doing right?
  221.  
  222. By the way, don't get upset about my IP numbers.  None of these nets are
  223. connected to anything and just exist on an experimental test bed.
  224.  
  225. ------------------------AUTOEXEC.NOS for 1.0.0.99------------
  226. ## ip setup
  227. ip address 1.0.0.99
  228. hostname dave.ards.dnd.ca.
  229.  
  230. ## ax25 setup
  231. ax25 mycall dave
  232. ax25 bctext "ARDS testbed Daves Machine"
  233.  
  234. ## attach interfaces
  235. attach asy 0x3f8 4 ax25 sl1 1025 768 9600
  236. ifconfig sl1 ipaddress 1.0.1.99
  237. ifconfig sl1 descr "AX25 Connection to Laptop"
  238.  
  239. attach packet 60 lan1 100 1500
  240. ifconfig lan1 ipaddress 1.0.0.99
  241. ifconfig lan1 descr "Packet Connection to DLAEEM"
  242.  
  243. ## Start Servers
  244. start ax25
  245. start ftp 
  246. start telnet
  247.  
  248. ## Routing
  249. route add 1.0.1/24 sl1
  250. route add 1.0.0/24 lan1
  251.  
  252. ip hport sl1 on
  253. ip hport lan1 on
  254. ax25 hport sl1 on
  255.  
  256. --
  257.  
  258. |------------------------------------------------------------|
  259. | Captain Dave Mercer M.Eng., P.Eng.                         |
  260. | Directorate of Land Armament and                           |
  261. |   Electronics Engineering and                              |
  262. |   Maintenance 2-3-3                                        |
  263. | National Defence Headquarters                              |
  264. | Ottawa, Ontario, Canada                                    |
  265. | K1A 0K2                                                    |
  266. |                                                            |
  267. | Voice: (819) 997-9831                                      |
  268. | Fax:   (819) 994-4246                                      |
  269. | EMail: mercer@dgs.dnd.ca                                   |
  270. | HAM: VE3XMJ                                                |
  271. |------------------------------------------------------------|
  272.  
  273.  
  274. -----BEGIN PGP PUBLIC KEY BLOCK-----
  275. Version: 2.3
  276.  
  277. mQCNAiw7jJkAAAEEALpAIvULlA/xvrzuR30NcLZE0HCHyGm5QR4ej8xM6k3AcH3T
  278. Q3NkgV2FK5f8t/fBAhO1+ffa5K7F10B4hPqKkAASNlk1PIx9ty5oUgxAlZnfya4V
  279. ScNIx0x2h2f3roRjiZLfNYM2zkm26sZhFQjVJxyNnluJq/xVb45/LyY+p9flAAUR
  280. tCBEYXZpZCBNZXJjZXIgPG1lcmNlckBuY3MuZG5kLmNhPg==
  281. =0azF
  282. -----END PGP PUBLIC KEY BLOCK-----
  283.  
  284. ------------------------------
  285.  
  286. Date: Wed, 24 Aug 94 20:27:08 PDT
  287. From: ihnp4.ucsd.edu!dog.ee.lbl.gov!agate!howland.reston.ans.net!vixen.cso.uiuc.edu!sdd.hp.com!svc.portal.com!portal!cup.portal.com!lgm@network.ucsd.edu
  288. Subject: What SB for Digital modes?
  289. To: ham-digital@ucsd.edu
  290.  
  291. all digital is on LSB on 20 meters
  292.  
  293. ------------------------------
  294.  
  295. Date: Thu, 25 Aug 1994 16:34:28 GMT
  296. From: ihnp4.ucsd.edu!agate!howland.reston.ans.net!europa.eng.gtefsd.com!newsxfer.itd.umich.edu!zip.eecs.umich.edu!yeshua.marcam.com!news.kei.com!world!dts@network.ucsd.edu
  297. To: ham-digital@ucsd.edu
  298.  
  299. References <1994Aug20.143652.9960@ke4zv.atl.ga.us>, <CuzyoI.8tt@world.std.com>, <33i45b$oao@acorn.acorn.co.uk>.com
  300. Subject : Re: Looking for DXCluster software
  301.  
  302. In article <33i45b$oao@acorn.acorn.co.uk>,
  303. Adrian Godwin <agodwin@acorn.co.uk> wrote:
  304. >In article <CuzyoI.8tt@world.std.com>,
  305. >Daniel T Senie <dts@world.std.com> wrote:
  306. >>
  307. >>How is the PacketCluster machine to know that the UI frame with a DX
  308. >>spot just got stomped by another station starting to transmit a frame?
  309. >>Packet radio does NOT run with Collision Detection in the way that
  310. >>Ethernet does. You cannot tell, when transmitting, that your frame
  311. >>has just gotten munched.
  312. >>
  313. >
  314. >It's not that difficult : most broadcast protocols work on a NAK-only
  315. >scheme - clients of the server respond only when they miss a packet,
  316. >and the server than retransmits it.
  317. >The method of detecting that missed packet varies, but a popular method
  318. >is to number the transmitted packets and complain when a hole appears in
  319. >the number sequence.
  320.  
  321. Adrian, thanks for your comments, and this is exactly what I was trying
  322. to call out. There are certainly solutions such as numbered packets
  323. which can be implemented. Essentially what you're doing then is to
  324. create another protocol layered atop the broadcast mechanism. It's
  325. not that different from the multicast implementations. I was primarily
  326. pinting out that the "simple" solution that had been mentioned was
  327. not sufficient.
  328.  
  329. >
  330. >This has some difficulties for a DX-Cluster style service : as I understand
  331. >it (I don't use DX Cluster) you expect transmissions at intervals, rather
  332. >than a continuous stream. Thus, you wouldn't know you missed one until
  333. >the next arrived - a second or an hour later. Regular empty packets, sent
  334. >just to ensure everyone was up to date, might be sufficent to fix this,
  335. >and there are more sophisticated schemes around to ensure this doesn't
  336. >itself become a bandwidth hog. These require that the server keep track 
  337. >of its clients rather than doing pure broadcast, but that's no worse than 
  338. >having multiple VCs.
  339.  
  340. Exactly. The frequency of packets is an issue. It would be necessary to
  341. send out null packets every 30 seconds or so to ensure all stations
  342. received the broadcasts in a timely fashion. Even 30 seconds may be
  343. too long... At some point you really clog the channel with null packets
  344. placed there to ensure naks happen correctly when needed...
  345.  
  346. >
  347. >However, I think you're correct to be concerned about low reliability of
  348. >packet systems - on typical terrestrial packet, the success rate is very
  349. >low. As a result, a protocol optimised for the assumption that most packets
  350. >get through (and don't require ACKing) might turn out disastrously wrong -
  351. >I think a successful broadcast scheme would require both a well-engineered
  352. >high-reliability transmission scheme (good paths, no hidden terminals etc)
  353. >and a protocol that gets no worse than multiple-VCs even in poor conditions.
  354. >It might work pretty well with a full-duplex repeater and extremely well
  355. >with a polled hub (where a small amount of reverse traffic can be effectively
  356. >free by imposing no additional overhead).
  357. >
  358. >I don't know how closely satellite operation approaches this (do they split
  359. >uplink and downlink packet frequencies ? ). I'd be interested to hear from 
  360. >users of the Pacsat broadcast system and even more interested to hear from 
  361. >anyone who has experimented with a terrestrial broadcast setup.
  362.  
  363. Dan
  364. -- 
  365. ---------------------------------------------------------------
  366. Daniel Senie                 Internet:     dts@world.std.com
  367. Daniel Senie Consulting                    n1jeb@world.std.com
  368. 508-779-0439                 Compuserve:   74176,1347
  369.  
  370. ------------------------------
  371.  
  372. Date: 25 Aug 1994 13:51:55 +0100
  373. From: ihnp4.ucsd.edu!agate!howland.reston.ans.net!EU.net!uknet!acorn!not-for-mail@network.ucsd.edu
  374. To: ham-digital@ucsd.edu
  375.  
  376. References <3306v8$jbi@vixen.cso.uiuc.edu>, <1994Aug20.143652.9960@ke4zv.atl.ga.us>, <CuzyoI.8tt@world.std.com>
  377. Subject : Re: Looking for DXCluster software
  378.  
  379. In article <CuzyoI.8tt@world.std.com>,
  380. Daniel T Senie <dts@world.std.com> wrote:
  381. >
  382. >How is the PacketCluster machine to know that the UI frame with a DX
  383. >spot just got stomped by another station starting to transmit a frame?
  384. >Packet radio does NOT run with Collision Detection in the way that
  385. >Ethernet does. You cannot tell, when transmitting, that your frame
  386. >has just gotten munched.
  387. >
  388.  
  389. It's not that difficult : most broadcast protocols work on a NAK-only
  390. scheme - clients of the server respond only when they miss a packet,
  391. and the server than retransmits it.
  392. The method of detecting that missed packet varies, but a popular method
  393. is to number the transmitted packets and complain when a hole appears in
  394. the number sequence.
  395.  
  396. This has some difficulties for a DX-Cluster style service : as I understand
  397. it (I don't use DX Cluster) you expect transmissions at intervals, rather
  398. than a continuous stream. Thus, you wouldn't know you missed one until
  399. the next arrived - a second or an hour later. Regular empty packets, sent
  400. just to ensure everyone was up to date, might be sufficent to fix this,
  401. and there are more sophisticated schemes around to ensure this doesn't
  402. itself become a bandwidth hog. These require that the server keep track 
  403. of its clients rather than doing pure broadcast, but that's no worse than 
  404. having multiple VCs.
  405.  
  406. However, I think you're correct to be concerned about low reliability of
  407. packet systems - on typical terrestrial packet, the success rate is very
  408. low. As a result, a protocol optimised for the assumption that most packets
  409. get through (and don't require ACKing) might turn out disastrously wrong -
  410. I think a successful broadcast scheme would require both a well-engineered
  411. high-reliability transmission scheme (good paths, no hidden terminals etc)
  412. and a protocol that gets no worse than multiple-VCs even in poor conditions.
  413. It might work pretty well with a full-duplex repeater and extremely well
  414. with a polled hub (where a small amount of reverse traffic can be effectively
  415. free by imposing no additional overhead).
  416.  
  417. I don't know how closely satellite operation approaches this (do they split
  418. uplink and downlink packet frequencies ? ). I'd be interested to hear from 
  419. users of the Pacsat broadcast system and even more interested to hear from 
  420. anyone who has experimented with a terrestrial broadcast setup.
  421.  
  422. -adrian
  423.  
  424. ------------------------------
  425.  
  426. End of Ham-Digital Digest V94 #285
  427. ******************************
  428.